Anonymous block trade matching system

ABSTRACT

Disclosed is an anonymous block trade matching system which allows users that wish to cross large blocks of stock to submit orders, or indications of interest, with the option of utilizing market peg benchmarks or future price cross benchmarks. Orders submitted may be subject to minimum thresholds, including a threshold requiring that the order represent ‘X’ % of average daily volume. After submission of a firm order in the system, an alert is generated to provide the order data to other users with potential to cross the order. Visibility of order data by other users may be restricted based upon a data interaction group to which the ordering user or the other user belongs. The system may provide users viewing order data with a capability of negotiating with the submitting user via a restricted two-way messaging interface. Flat rate and rebate/fee cost models may be utilized as a means for charging a user for access to the system.

This application includes material which is subject to copyrightprotection. The copyright owner has no objection to the facsimilereproduction by anyone of the patent disclosure, as it appears in thePatent and Trademark Office files or records, but otherwise reserves allcopyright rights whatsoever.

FIELD OF THE INVENTION

The present invention relates in general to the field of computersystems, and in particular to a novel computer system for facilitatingblock trade securities transactions.

BACKGROUND OF THE INVENTION

Block trading, also referred to as “crossing,” is a well-known type ofsecurities transaction wherein trades are privately negotiated apartfrom the public auction market. Block trading allows sell side tradersand buy-side traders to reduce transaction costs, such as ticket,execution and settlement costs. While block trading is most oftenperformed through manual negotiation, several matching engines andalternative trading systems have been known in the prior art formatching securities buyers with sellers and for matching securitiessellers with pools of liquidity.

Some such matching engines, previously known as Instinet, VT and CBX(the “Instinet Systems”), provided by Instinet, allow users to submitanonymous orders. The systems distribute order alerts to other users ofthe system who may have interest in performing a transaction with theuser whose order triggered the order alerts. When order alerts aredistributed and negotiated upon between parties, the parties areanonymous to each other. In this respect, order alerts allow parties toseek a natural counterpart to trade with while controlling informationleakage and protecting trading strategy.

Users of such systems control what order information the market sees,showing externally only a minimum execution size and price, whilenegotiating actual size and price with natural counterparties.

However the Instinet Systems and other matching engines which providefor block trading are limited in several respects. While they haveprovided a means for continuous off-exchange crossing, they have notprovided a sufficient capability to submit orders using market pegbenchmarks or future price cross benchmarks via a web based terminalapplication. While such systems have provided a means for transmittingalerts to subscribers to advise them of potential trading opportunities,no means has existed for permitting the user to control which users ortypes of users will receive such alerts. Additionally, systems thatprovide for block trading have typically provided only limited means fornegotiation between the parties, and such negotiations were onlyavailable to customers utilizing proprietary trading platforms on aproprietary data network.

OBJECTS AND SUMMARY OF THE INVENTION

It is therefore an object of the invention to provide an improvedanonymous block trade matching system.

It is a further object of the invention to provide a system whichenables participants to cross large blocks of international or nationalstocks anonymously to cut ticket, execution and settlement costs whilealso reducing market impact and spread costs.

In preferred embodiments, the invention provides an anonymous blocktrade matching system which allows users that wish to cross large blocksof stock to submit orders, or indications of interest, with the optionof utilizing market peg benchmarks or future price cross benchmarks.Orders submitted may be subject to minimum size thresholds. Aftersubmission of a firm order in the system, an alert is generated toprovide the order data to other users with potential to cross the order.Visibility of order data by other users may be restricted based upon adata interaction group to which the ordering user or the other userbelongs. The system may provide users viewing order data with acapability of negotiating with the submitting user via a restrictedtwo-way messaging interface. Flat rate and rebate/fee cost models may beutilized as a means for charging a user for access to the system.

The invention therefore provides a mutually beneficial trading solutionwhere both trade parties can benefit from trading directly with anatural counterpart.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other objects, features, and advantages of theinvention will be apparent from the following more particulardescription of preferred embodiments as illustrated in the accompanyingdrawings, in which reference characters refer to the same partsthroughout the various views. The drawings are not necessarily to scale,emphasis instead being placed upon illustrating principles of theinvention.

FIG. 1 shows a schematic block diagram illustrating a system inaccordance with an embodiment of the invention.

FIG. 2 a shows a graphical illustration of an interface by which thesystem receives an order in accordance with one embodiment.

FIG. 2 b shows a graphical illustration of an interface by which thesystem receives an order in accordance with an embodiment.

FIG. 3 is a high-level functional flow diagram illustrating a processfor generating and distributing alerts.

FIG. 4 shows a graphical illustration of a web application interface inaccordance with one embodiment.

FIG. 5 shows a graphical illustration of a two-way messaging systeminterface.

FIG. 6 shows a graphical illustration of a search window in accordancewith one embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Reference will now be made in detail to the preferred embodiments of thepresent invention, examples of which are illustrated in the accompanyingdrawings.

The present invention is described below with reference to blockdiagrams and operational illustrations of methods and devices to makeand use a block trade matching system in accordance with the invention.It is understood that each block of the block diagrams or operationalillustrations, and combinations of blocks in the block diagrams oroperational illustrations, may be implemented by means of analog ordigital hardware and computer program instructions. These computerprogram instructions may be provided to a processor of a general purposecomputer, special purpose computer, ASIC, or other programmable dataprocessing apparatus, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, implements the functions/acts specified in the block diagramsor operational block or blocks. In some alternate implementations, thefunctions/acts noted in the blocks may occur out of the order noted inthe operational illustrations. For example, two blocks shown insuccession may in fact be executed substantially concurrently or theblocks may sometimes be executed in the reverse order, depending uponthe functionality/acts involved.

FIG. 1 illustrates an embodiment of the disclosed anonymoustrade-matching system 10 for trading natural large blocks of stockacross international or national markets. The system 10 provides userswith the ability, during continuous trading hours, to submit orders forblock trades. When a firm order is placed, order data for the order maybe included in a block match “alert”, or “indication of interest (IOI)”,which is selectively distributed to other users to alert such users tothe opportunity to enter into a cross trade.

A block matching engine 12 utilizes algorithms, discussed further below,to match orders. A core database 14 is provided for storing historicalinformation regarding trades and tracking the trading history ofclients. In one embodiment the core database is the generator of alerts.However, as will be understood by those of ordinary skill in the art,alerts may be generated by any server in the system without departingfrom the spirit and scope of the invention. Clients may access thetrade-matching system 10 to place orders and/or receive alerts via aninterface with an inhouse trading application 24 that communicates withan inhouse trading platform 16, via an interface with an externaltrading system 18 that communicates with inhouse trading platform 16, orvia a web client 20 that connects via he internet with a webinfrastructure server 22.

The external trading system 18 may communicate with the trade-matchingsystem 10 using a suitable standard or proprietary order protocol. Oneexample of a suitable protocol is the Financial Information eXchange(FIX) protocol published by FIX Protocol maintained by FIX Protocol Ltdof London, U.K. The FIX protocol is a well-known electroniccommunications protocol for international real-time exchange ofinformation related to the securities transactions and markets. FIXmessages are formed from a number of fields, each field is a tag valuepairing that is separated from the next field by a delimiter SOH. TheTAG is a string representation of an integer that indicates the meaningof the field. The value is an array of bytes that hold a specificmeaning for the particular TAG. For example, “TAG 48” is securityID andis a string that identifies the security, “TAG 22” is IDSource and is aninteger that indicates the identifier class being used. In the main thevalue is readable text. However, fields can be encrypted and thus thevalue can be pure binary and include the normal delimiter SOH—binaryfields are always preceded by a length field. The FIX protocol definesmeanings for most TAGs and a range of TAGs is reserved for private usebetween consenting parties. The FIX protocol also defines sets of fieldsthat make up a particular message. Within the set of fields some aremandatory under the protocol and others are optional.

The web infrastructure server 22 provides a secure interface to webclients accessing the system over the internet, and sets user levelpermissions. The web client 20 runs an internet-delivered webapplication that allows users to view trading opportunities in the formof “alerts,” which are discussed in further detail below. The webapplication may additionally provide the user with an ability to set upfilters to prevent their receipt of an overwhelming number of alerts formarket sectors in which such user is not interested. The web applicationmay also include instant messaging functionality for allowing clients tocommunicate with each other using permitted phrases in furtherance ofnegotiating a trade, as is discussed in further detail below. The Webapplication may further incorporate an advanced search screen thatallows users to input criteria of their choice to display orders thatare placed with the system. The web application in one embodimentestablishes a real time data feed from core database so that changesmade in core database intraday will be reflected instantly in the webfront end. The presentation of the data by the web application may beaccomplished by configuring it to display four types of windows: a stocklist window displaying an order-by-order list of live, traded, cancelledand expired orders on the system; a market depth window showingconsolidated data by price for live, traded, cancelled and expiredorders, an alert window displaying IOI's relating to orders placed inthe system, and a two-way message window used for negotiating withparticipants on existing orders, expired/cancelled orders and tradedorders.

FIGS. 2 a and 2 b show graphical illustrations of an interface by whichthe system receives a securities order in accordance with oneembodiment. Current market data for a security is displayed in the topthird of the interface. In the center of the interface is a series offields with selection options. A “Quantity” field allows the user tospecify a quantity associated with the order. A “Display Quantity” fieldprovides a combo control to allow a user to specify display quantity,subject to minimum display criteria, with the option to select systemvalues using a drop down. Such system values may be, e.g., “1000,”“2000,” “3000,” “4000,” “5000,” “10000,” “15000,” “20000,” or “25000.”The default value may be set as “All”, in which case the entire orderwill be displayed. An “Expiry” field provides a combo control to allow auser to specify an expiry time for the order. Users can access a list ofsystem values using the drop down. Such system values may be, e.g.,“Day,” “GTD,” “Blotter,” “+5 mins,” “+10 mins,” “+1 hr,” or “IOC.” Thedefault value required may be set to “Day”.

The order screen of FIGS. 2 a and 2 b in one embodiment includes a“Display Price” field which prompts the user to select a benchmark inconnection with the order. Orders may be submitted using, e.g., marketpeg benchmarks ‘Mid’, ‘Bid’ and ‘Ask’, and future price cross benchmarks‘VWAP’, ‘Open’ and ‘Close’. By providing the ability to submit ordersusing these benchmarks during continuous trading hours, the system canoffer a mutually beneficial trading solution where both trade partiescan benefit from trading directly with a natural counterpart, and canthus provide a means for cutting ticket, execution and settlement costsby eliminating the middleman while also reducing market impact andspread costs.

If the user specifies a primary peg benchmark (e.g., ‘Mid’, ‘Bid’ or‘Ask) in the “Display Price” field of FIGS. 2 a and 2 b, the systemprovides the option of adding a hard limit to the order. In such case,the primary peg benchmark price moves as the market moves, but the useris ultimately protected by their hard limit should the market movebeyond their upper limit price. The order will be displayed using thealphabetic peg benchmark value, e.g., MID, and not the actual pricevalue. If the market moves beyond the user's hard limit, the order typewill change to a hard limit order automatically and will then displaythe hard limit price in numeric format. If the market moves favorablyagain, the order will again revert to an alphabetic value. When a match(person entering order for opposite side at same benchmark value) isfound, trades will be issued at the primary price of the specifiedbenchmark at the time the match occurred.

If the user specifies a primary future cross price benchmark value, e.g.‘VWAP’, ‘Open’ or ‘Close’, in the “Display Price” field of FIGS. 2 a and2 b, no option is given to specify a hard limit. The order will be setat the chosen benchmark, and upon finding a match—a person entering anorder for opposite side at same benchmark value—an indicative fill willbe sent to both participants at the primary market last close price.When the Primary Exchange publishes its official price that the userspecified as their future cross benchmark, trade corrects will be sentto both participants at the official cross price.

The system may be configured to require a user entering an order toadhere to one or more minimum thresholds, on a per-stock basis, in orderto participate in the block matching functions provided by the system.Such thresholds include a “% ADV” threshold and a Share Quantitythreshold. To meet the % ADV threshold, an order must represent ‘X’ % ofAverage Daily Volume. To meet the Share Quantity threshold, an ordermust be ‘X’ number of shares. If an order not meeting a requiredthreshold is entered in the system, it may be rejected by the system.Thresholds for a particular stock ordered may be set at any value, butwill generally be based on liquidity of the stock and price level of thestock ordered.

The system may further be configured to provide users with the facilityto include their order data on block match alerts, or indications ofinterest (IOI's), maximizing the potential to find a suitable party tocross with. The system in various embodiments segregates users into fourdistinct data interaction groups, and makes order data visible to usersin accordance with the group to which they belong. In one embodiment,the four groupings are: Buy Side, Sell Side, Market Maker and DarkProvider. The constituency of these groups, and the extent to which theyare able to view orders in the system, is summarized in the table below:

Group Type Visibility Buy Side Institutions Full visibility of Buy andSell side Typical Hedge orders. No visibility of Dark Funds orders. SellSide Broker/Dealer Restricted - at discretion of Prop Desks participantposting liquidity Market Maker Market Maker Restricted - at discretionof participant posting liquidity Dark Participants that do Zerovisibility of orders from Providers not want any all groups. visibilityof their orders

FIG. 3 is a high-level functional flow diagram illustrating a processfor generating and distributing alerts. The process begins at step 310with the receipt of a firm order in the system. Users must enter a firmorder into the block matching system in order to trigger an alert/IOI.The order data is first sent to the core database at step 312. At step314, the order data is examined to determine if the user placing theorder has designated himself as a dark provider. Dark Providers willnever see any order data for orders placed in the block matching system,but instead are able to interact with orders as a blind participant.Their orders are not visible to any of the participating groups. Thus,if the user placing the order is a dark provider, no alert is generatedand the alert generation process is stopped at step 316. Otherwise, theprocess continues to step 318. At step 318, the order data is examinedto determine whether the user has added a “hidden” instruction to theorder. If a user adds a “Hidden” instruction when placing an order, theorder will not be displayed in the order book and no alert will begenerated.

If the order is not designated as hidden and is not placed by a darkprovider, the process proceeds to generate an alert at step 322. Thecontent of such alert is discussed below with reference to FIG. 4. Withcontinued reference to FIG. 3, the order data is then examined todetermine whether the user has included therein a sell side instruction.In accordance with one embodiment, orders placed in the system are onlyvisible to buy side users by default. Buy side users, however, have theoption to make their orders visible to the sell side/makers makers byadding a “sell side” instruction to their order. Such sell sideinstruction may be indicated at the time of the order, e.g., by checkinga “sell side” box shown in FIGS. 2 a and 2 b. Alternatively, suchinstruction may be set automatically by the system in accordance with auser's user profile. Sell side users are able to enter orders into thesystem, but their orders will always be visible to the Buy Side. Theyare, however, able to hide orders from other sell side/market makerusers by not adding the ‘Sell Side’ instruction to their order.

Based upon a user's trade history data stored in the core database 14(FIG. 1), and specifically the volume of trades which the particularuser has conducted within a specified historical time frame (e.g., thepast one month, past four months, past six months, etc.) a particularclient may be assigned a “tier.” As an incentive for using the system,the system may be configured to provide higher tiered clients, e.g.,those with a higher volume of trades historically, with alerts inadvance of lower tiered clients. In one embodiment, there are two tiersof users, tier one and tier two. Tier one users receive alerts ahead oftier two users and other participants. In one embodiment, the system isconfigured to transmit alerts to tier one users one minute ahead of tiertwo users. The system may be configured to require users to have met apreset minimum volume of trades within a specified time period to beeligible for tier one alerts. For example, users may be required to havetraded on the system at least once in the last week. Alert subscriptionsare checked by the system when a new order is placed in the system todetermine which users will receive the alert first. The system may beconfigured such that tier one alerts are only available through inhousefront ends, and all external alert subscribers are assigned to tier two.

FIG. 4 shows a graphical illustration showing an example of a webapplication interface, including an alert window, a stock list window,and a negotiation window, in accordance with one embodiment. Inaccordance with one embodiment, the alert window displays alerts/IOIsfor orders as and when they placed in the system, subject to the user'stier target level and client group (e.g., buy side, sell side, or darkprovider) visibility. The window may be set as a permanent displaywindow by default. However, the system may be configured to provideusers with the ability to right click, for example, on the window andselect ‘set as pop-up window’ if they prefer the window to open uponreceipt of a new alert. The alert window displays the Stock, Side andQty for each new alert/IOI. The system may be configured to cause analert/IOI to expire and be cleared from the alert window after apredetermined period of time, e.g., two minutes.

As shown in FIG. 4, a stock list window may be provided in the webapplication interface for viewing and interacting with current andhistorical order data. The interface allows users who have asubscription to view order data for orders placed in the system to seelive orders as well as traded, cancelled and expired order history overa specified amount of time, e.g., over the last thirty days. Each ordermay be presented on a separate line, with lines sorted such that liveorders appear at the top, sorted by date and time, followed by traded,cancelled, and expired order history, which are each also sorted by dateand time. The system may be configured such that when a new live orderis added to the system for a stock that is displayed in a user's stocklist window, the line for the order is displayed in a distinct colourwhich gradually fades over a period of time, e.g., two minutes, toreveal the underlying row colour for the order.

Negotiation on historic order data, as well as live orders, is providedvia a two-way messaging system that is activated, e.g., viadouble-clicking on a particular order displayed in the stock list windowor the alert window shown in FIG. 4, or by activating a button or othercontrol associated with the order in such windows. FIG. 5 shows agraphical illustration of a two-way messaging system interface. Thetwo-way messaging system may be provided as a real-time messagingsystem, e.g., instant messaging, or may be provided as a non-real-timemessaging system such as an e-mail system. The two-way messaging systemmay be provided as part of the web application running on web client 20(FIG. 1).

Users can use the two-way messaging interface of FIG. 5 to target anorder of interest and strike up a restricted message with the owner ofthe historic order using predetermined hard-coded phrases permitted bythe system through restricted keystrokes or button presses. Keyboardstickers may be provided to users to associate particular keys withparticular permitted phrases. For example, the “S” key may be associatedwith the phrase “Sorry not at present” and the “W” key may be associatedwith the phrase “Will you deal at.” The hard-coded phrases may similarlybe implemented in the form of a series of phrases associated with acorresponding series of soft buttons appearing on the interface of FIG.5. In such embodiments, the system limits the parties to communicationsusing a finite number of phrases associated with a finite number ofcorresponding buttons, as well as the number keys on the user'skeyboard. Numeric keys are preferably not restricted.

Below is an exemplary list of the messages permitted from thenegotiation window using soft buttons (e.g. Sorry) activated by themouse or hot keys (e.g. W) activated by the keyboard:

Button label Full text message Keyboard Hot Key Yes: Yes Y No: No NWill: Will you deal at_? W Sorry: Sorry, not at present S Best: My bestprice is_(—) B Call: Need to make a call, be right back C Limit:Currently limited at_(—) L Neg ID: Requests a negotiation ID I

The negotiation window of FIG. 5 depicts a negotiation between twoparticipants. The first participant has sent a message ‘will you deal at22.75?’ to the owner of order WTB.L, Sell, 1,000,000. The order owner isabout to respond with ‘Sorry not at present’.

When a negotiation has been agreed upon in terms of price or size, usersmay request a system-generated negotiation ID that can be attached to afirm order to lock the order from trading with anyone other than theirnegotiation partner. This ID may be system generated by the webapplication and visible to both users. Both users submit an order withtheir agreed order parameters (size, price), adding the negotiation IDto their order in a negotiation text field. This effectively locks theorder for the two participants and prevents the user's order fromcrossing with any party other than the one with which they have beennegotiating. The completed order is cleared via external trade clearing(FIG. 1).

FIG. 6 shows an example of an advanced search window in accordance withone embodiment of the invention that allows a user to input criteria oftheir choice to display orders that have been placed with the system.Once logged in to the web application, a user is presented with thesearch window. The user can utilize this window to build queries on anad hoc basis, or he can set up his preferred search criteria and savethe query so that on subsequent log ins all that is required of him isto select the query name and select a “Go” button or similar control.

In the search window of FIG. 6, a “Symbol” fields provides a means for auser to identify a specific stock, to identify multiple stocks using acomma separator, or select one or more stocks from a list. A “SymbolType” field allows the user to identify the type of symbol entered inthe Symbol field, e.g., “Instinet Symbol,” “RIC,” Cusip,” “Sedol” andreferences to third party vendor products, such as Bloomberg. An“Exclude Alerts” field provides the user with the capability ofexcluding from the search results those orders for which an alert hasbeen generated. A “Side” field provides a drop-down list allowing a userto limit the search to either buy-side or sell-side orders. An “OrderType” field allows the user to limit the search to orders that areeither live, traded, cancelled or expired. A “Quantity” field provides ameans for the user to specify a range, e.g., 10,000-20,000. An“Instrument Type” field allows the user to specify a type of instrumentto search for, e.g., UKE, ITE, USE, USEO, or CAE. A “Market” fieldallows the user to restrict his search to a particular market, e.g.,U.K. or U.S. A “Region” field similarly allows the user to restrict hissearch to a particular region, e.g., Europe, US, or Asia, or to multipleregions using a comma separator. A “Currency” field allows the user torestrict the search to orders in a particular currency, e.g., GBP, GBp,USD, JPY, HKD, EUR, CHE, NOK, DKK, ZAR, or All. A “% ADV” field allowsthe user to specify a range, e.g., between 5% and 200%, for thepercentage of order quantity that is for the specified stock. An“Include Hidden” field allows the user to include in the search resultsorders which were placed with the “Hidden” instruction discussed above.A “Search BlockMatch” button causes the query to execute with the abovecriteria, and returns a list of orders in the system that matches suchcriteria.

The system may be configured to provide users with a mutually beneficialcost model for two parties that wish to cross large blocks of stockoff-exchange. In this respect, the system may provide two cost modeloptions for users—a flat rate cost model and a rebate/fee cost model.

The flat rate cost model option offers users who want a flat rate costmodel with access to the system at a flat rate cost per trade, e.g., 2.5bp per trade on DMA orders or orders placed with the system through arepresentative of the system proprietor. Orders that are placed with thesystem using one of several value-adding algorithms that automate theaccessing of liquidity may be offered at another, higher flat rate,e.g., 3 or 4 bp.

The rebate/fee cost model option provides users with the ability toconduct a transaction where the buying supplier gets a net price of,e.g., 10 minus 2.5 bp and the seller gets a net price of, e.g., 10 minus7.5 bp. To accommodate the rebate/fee model is configured toautomatically calculate client trades as a fee or rebate on a per-tradebasis based on which client was the provider or taker of liquidity.Alternatively the system can be configured to allow all trades to beprocessed under a flat rate model and then at the end of the day ormonth manually override each rate with the new rate after allrebates/fees have been taken into account.

Thus, the system may be configured to offer participants that postdirectly to it the ability to ‘take liquidity’ at a flat rate, e.g. 7.5bp, while ‘liquidity providers’ benefit from a rebate, e.g. 2.5 b, onorders. The system may be further configured such that participants thattrade roughly an equal proportion of posting and taking liquidity canaccess the system at a flat rate, such as the mid point of the grosscommission, for direct posting and taking liquidity, e.g. 2.5 bp, on alltrades.

While the invention has been particularly shown and described withreference to a preferred embodiment thereof, it will be understood bythose skilled in the art that various changes in form and details may bemade therein without departing from the spirit and scope of theinvention.

1. An anonymous block trade matching system, comprising: at least oneserver configured to receive via a network order data for an order of asecurity, said order data comprising a user's specification of a pricebenchmark for said order, said price benchmark being selected from thegroup consisting of: a peg value with a hard limit, a peg value withouta hard limit, or a future cross price; a core database having storedtherein said order data, said order data including said price benchmark;and, an alert generator configured to use said order data to transmit toat least one prospective trading party an alert anonymously describingsaid order.
 2. The anonymous block trade matching system in accordancewith claim 1, wherein said at least one server is further configured toreceive said order data via a private network.
 3. The anonymous blocktrade matching system in accordance with claim 1, wherein said at leastone server is further configured to receive said order data via apublicly accessible network.
 4. The anonymous block trade matchingsystem in accordance with claim 1, wherein said at least one servercomprises a first server for receiving said order data via a publiclyaccessible network and a second server for receiving other order datavia a private network.
 5. The anonymous block trade matching system inaccordance with claim 1, further comprising a matching engine forfinding an opposite side order meeting said benchmark value.
 6. Theanonymous block trade matching system in accordance with claim 1,wherein said alert generator is further configured to generate saidalert such that an alphabetic benchmark value, and not an actual pricevalue, is displayed in said alert to said prospective trading party. 7.The anonymous block trade matching system in accordance with claim 6,wherein said price benchmark comprises a peg value and said alphabeticbenchmark value is selected from the group consisting of: MID, BID, orASK, said benchmark value referencing a primary market for the price ofsaid security.
 8. The anonymous block trade matching system inaccordance with claim 6, wherein said price benchmark comprises a futurecross price and said alphabetic benchmark value is selected from thegroup consisting of: VWAP, OPEN or CLOSE, said VWAP benchmark valuereferencing a price determined at the discretion of a proprietor of thesystem and said OPEN and CLOSE benchmark values referencing a primarymarket for the price of said security.
 9. The anonymous block tradematching system in accordance with claim 1, wherein the system isfurther configured such that if an exchange on which said security istraded moves beyond said user's specified hard limit an order typeassociated with said order changes automatically from a price benchmarkorder type to a hard limit order type.
 10. The anonymous block tradematching system in accordance with claim 9, wherein the system isfurther configured such that said alert displays a hard limit price innumeric format after said change from a price benchmark order type to ahard limit order type.
 11. The anonymous block trade matching system inaccordance with claim 9, wherein the system is further configured suchthat if, after said change in order type, the exchange moves below saiduser's specified hard limit said order type reverts automatically tosaid price benchmark order type.
 12. The anonymous block trade matchingsystem in accordance with claim 11, wherein the system is furtherconfigured such that said alert again displays an alphabetic benchmarkafter said change from a hard limit order type to a price benchmarkorder type.
 13. The anonymous block trade matching system in accordancewith claim 8, wherein the system is further configured such that after aprimary exchange publishes an official price for the security orderedusing a future cross benchmark, trade corrects are sent to bothparticipants at the official cross price.
 14. An anonymous block tradematching system, comprising: a server configured to receive order datafor an order of a security; a core database having stored therein saidorder data; and, an alert generator configured to use said order data totransmit to a plurality of prospective parties an alert anonymouslydescribing said order, said alert generator being configured toselectively send said alert to said plurality of prospective partiesbased upon an indication in said order data of which type of users areto receive said alert.
 15. The anonymous block trade matching system inaccordance with claim 14, wherein said alert generator comprises adatabase.
 16. The anonymous block trade matching system in accordancewith claim 14, wherein said indication in said order data of which typeof users are to receive said alert comprises an indication that thealert is to be hidden from a group of users.
 17. The anonymous blocktrade matching system in accordance with claim 16, wherein said group ofusers comprises all users.
 18. The anonymous block trade matching systemin accordance with claim 16, wherein said group of users comprises lessthan all users.
 19. The anonymous block trade matching system inaccordance with claim 14, wherein said indication in said order data ofwhich type of users are to receive said alert comprises an indication ofwhether sell-side users are to receive said alert.
 20. The anonymousblock trade matching system in accordance with claim 14, wherein saidalert generator transmits said alert to buy side users by default, andwherein said indication in said order data of which type of users are toreceive said alert comprises an indication of whether sell-side usersare to receive said alert.
 21. The anonymous block trade matching systemin accordance with claim 14, wherein said indication in said order dataof which type of users are to receive said alert comprises an indicationof whether market maker users are to receive said alert.
 22. Theanonymous block trade matching system in accordance with claim 14,wherein said alert generator is configured to prevent a dark providerfrom viewing said order data.
 23. An anonymous block trade matchingsystem, comprising: a server configured to receive order data for anorder of a security; a core database having stored therein said orderdata; and, an alert generator configured to use said order data totransmit to a plurality of prospective parties an alert anonymouslydescribing said order, said alert generator being configured to transmitsaid alert to a first subset of said plurality of prospective partiesand subsequently to transmit said alert to a second subset of saidplurality of prospective parties after the elapsing of a predeterminedtime period from said transmission of said alert to said first subset ofsaid plurality of prospective parties.
 24. The anonymous block tradematching system in accordance with claim 23, wherein said predeterminedtime period is one minute.
 25. The anonymous block trade matching systemin accordance with claim 23, wherein the system is further configuredsuch that to be eligible to be included in said first subset a user musthave utilized the system in the past to conduct a number of securitiestrades.
 26. The anonymous block trade matching system in accordance withclaim 25, wherein said number of securities trades is one.
 27. Theanonymous block trade matching system in accordance with claim 25,wherein said eligibility is conditioned upon said user having utilizedthe system within a predetermined past time period.
 28. The anonymousblock trade matching system in accordance with claim 27, wherein saidpredetermined past time period is one week.
 29. The anonymous blocktrade matching system in accordance with claim 23, wherein said alertgenerator is configured to transmit said alert by the placement of a neworder.
 30. The anonymous block trade matching system in accordance withclaim 23, wherein said alert generator is configured to transmit saidalert by the placement of a firm order.
 31. An anonymous block tradematching system, comprising: a server configured to receive order datafor an order of a security by a first user; a core database havingstored therein said order data; an alert generator configured to usesaid order data to transmit to at least a second user an alertanonymously describing said order; and, a client configured to displayto said second user a two-way messaging interface that provides for anegotiation conversation between said first user and said second user,said two-way messaging interface restricting communication from at leastone of said first user and said second user to a finite set of phrases.32. The anonymous block trade matching system in accordance with claim31, wherein said two-way messaging interface is configured to restrictcommunication from both said first user and said second user to saidfinite set of phrases.
 33. The anonymous block trade matching system inaccordance with claim 31, wherein said two-way messaging interface isconfigured to translate a keystroke by said first user into anegotiating phrase and to transmit said negotiating phrase to saidsecond user.
 34. The anonymous block trade matching system in accordancewith claim 31, wherein said two-way messaging interface is configured totranslate a soft button press or mouse click by said first user into anegotiating phrase and to transmit said negotiating phrase to saidsecond user.
 35. The anonymous block trade matching system in accordancewith claim 31, wherein the system is configured such that when anegotiation has been agreed upon between said first user and said seconduser using said two-way messaging interface, the system generates anegotiation ID that is attached to said order data and locks the orderfrom trading with any party other than said first user and said seconduser.
 36. An anonymous block trade matching system, comprising: a serverconfigured to receive order data for an order of a security, said orderdata consisting of an indication that a net price improvement will beprovided to a liquidity provider placing said order; a core databasehaving stored therein said order data; and, a matching engine forfinding an opposite side order matching said order of a security. 37.The anonymous block trade matching system in accordance with claim 36,further comprising an alert generator configured to use said order datato transmit to at least one prospective trading party an alertanonymously describing said order.
 38. An anonymous block trade matchingsystem, comprising: a server configured to receive order data for auser's order of a security; a core database having stored therein saidorder data; and, a matching engine for finding an opposite side ordermatching said order of a security, said matching engine being configuredto reject said user's order if said order does not adhere to a minimumsize threshold assigned to said security.
 39. The anonymous block tradematching system in accordance with claim 38, wherein said minimum sizethreshold comprises liquidity of said security.
 40. The anonymous blocktrade matching system in accordance with claim 38, wherein said minimumsize threshold comprises a price level of said security.
 41. Theanonymous block trade matching system in accordance with claim 38,wherein said minimum size threshold comprises a share quantity of saidsecurity.
 42. The anonymous block trade matching system in accordancewith claim 38, wherein said minimum size threshold comprises an averagedaily volume of shares of said security traded on an exchange.
 43. Theanonymous block trade matching system in accordance with claim 38,further comprising an alert generator configured to use said order datato transmit to at least one prospective trading party an alertanonymously describing said order.